Introduction

     The population of climbers is exploding and we need more and better access to data to make the sport more accessible. I am using data provided from OpenBeta, a nonprofit built and run by climbers that enables “open access and innovative uses of climbing data” (1). I built a Shiny app that includes a map of sport and trad climbing routes in Oregon ranked by route quality and a recommendation engine tailored to the user of any skill level.
     Following the sport of climbing’s Olympic debut in Tokyo 2021 and the success of films like Free Solo featuring Alex Honnold (2018) and The Dawn Wall featuring Tommy Caldwell (2018), the industry is seeing historic growth and opportunities for new, profitable markets. According to Forbes, Google searches that included the term “climbing” reached an all time high in the first week of August 2021; the same time frame that men’s and women’s combined events were held (2). Not only is the sport gaining a bigger audience, but it is also attracting regular people like you and me to take a crack at the crag. Following the pandemic, nearly 100 climbing gyms have opened in North America and profits of El Cap, one of America’s largest operators of climbing facilities, saw a 100% increase in online interactions (2).
           One concern with the sport’s booming popularity is the barrier to entry and as a result, there has been a push to make the sport more accessible. In addition, there are only a few databases with outdoor climbing routes that are in access to the public like The Mountain Project or 8A. Without these platforms, climbers who are looking to hit their local crag or boulder may not be able to find routes or know about the quality of them if they do not already have community or word of mouth. While these websites have provided helpful tools to climbers of all experience and skill levels, they are still heavily lacking data and scrapings of these platforms have resulted in DMCA takedowns or lawsuits (3). At the bare minimum, we need better and easier access to climbing data so that data scientists like myself can work to advance the sport for others. As the sport grows so will the influx of data, and with any field that is expanding and rapidly changing, data science can add value to it by making better-informed decisions for multiple stakeholders, generating new insights about its players and audience, and increasing the overall experience for users.
      OpenBeta is a non-profit built and run by climbers that enables “open access and innovative uses of climbing data” (1). Though they have also faced several challenges with their attempt to use onX’s data from the Mountain Project with copyright infringement and blocked repositories, according to Outside Learn (3). At the moment their data is public, and Github recently reversed the DMCA takedown thanks to legal efforts from the owner, Viet Nguyen, who is “empowering the community with open license climbing betas and source tools” (1). His goal for OpenBeta is to make climbing data more like an open source project, which in turn would help platforms like Mountain Project to increase their recommendation systems, geolocation data, and the accuracy of submissions (3). In addition to pushing for accessible data, the OpenBeta also posts articles that fit the needs of any climber in STEM: tutorials, current events, and project inspirations like recommendation systems and route quality maps. The community that OpenBeta is fostering aligns heavily with the forward mentality of climbing currently which is: don’t be a gatekeeper, spread the beta, and anyone is capable.
      As a young climber and data scientist, I found myself incredibly inspired by OpenBeta’s work and wanted to support the nonprofit by using their data and some of their resources for my capstone project. I want to leverage climbing data to influence decision making for climbers of all skill sets and as a result, contribute to the overarching goal of OpenBeta which is to make the sport of climbing safer, more knowledgeable, and more accessible. Recommendation systems are extremely powerful and if done well, can be a great tool for young climbers when exploring outdoor routes. To get a better understanding of the data and to ensure the viability of this goal, I am performing an exploratory data analysis of the OpenBeta data.

EDA

In my process, I took all of the Oregon ratings from the OpenBeta. I first wanted to work with West Coast for a couple reasons. For one, the Sierra Nevada of California and the Cascade Range of the Pacific Northwest are prime western U.S. rock climbing locales. In addition the West Coast is scattered with popular climbing spots (i.e. Yosemite, Joshua Tree, Smith Rock) but there is a common misconception that these areas only have expert graded routes. In reality the opposite is true, and there are actually more beginner to moderate routes than expert ones.

We are only using routes with grades that are in the Yosemite Decimal System, which is the traditional difficulty rating for routes in the US. According to the Yosemite Decimal System, a 5.0 to 5.7 is considered easy, 5.8 to 5.10 is considered intermediate, 5.11 to 5.12 is hard, and 5.13 to 5.15 is reserved for a very elite few. This means that the app will be of use to any climber, as some local classics come even in lower grades.

Furthermore, I decided to hone in on Oregon routes because of the national coverage and booming popularity of California routes. Little people know that the birthplace of sport climbing was brought to Oregon’s Smith Rock State Park by Alan Watts, a famous climbing pioneer, in 1986 (7). Not only is some of the best climbing in the nation found in Oregon’s Smith Rock, there are also hidden gems right in Portland’s backyard that I had to do significant research as a climber to find. It would be even harder for a new climber to discover some of these on their own. Not to mention that most of these routes are for climbers of all skill sets. The idea of my project is that anyone can have access to local classics even in lower grades.

One dataset I used from OpenBeta contains all route ratings in Oregon along with the route ID, grade, name, and type (trad, sport, ice, bouldering, etc.).I’m going to look at only trad and sport routes on the West Coast, which are the most two popular types of outdoor climbing. A limit of this method is that we lose routes that could be both sport and trad. Another dataset I used had aggregate rating data from OpenBeta along with the location of parent walls to use for plotting. The features I used from this dataset are the parent wall ID, name, and location along with the state and ARQI rating (this metric is explained later).

We can see that our data is dominated by sport routes (after all, Oregon is the birth place of sport climbing). This raised a bias concern with an Item Based Collaborative Filtering recommendation system. With that being said, sport climbing is easily the most popular form of climbing nowadays. Not only is trad climbing out of date and mostly done by the pros, it is also extremely expensive and a result, a barrier to entry to the sport itself. Therefore I felt okay about this data imbalance when making a recommendation to a new user: they probably don’t want to be recommended trad routes for lower levels. As part of my exploratory data analysis, I also wanted to get a breakdown of classic routes. As a metric for route quality, we can look at the aggregate metric RQI or ARQI. The RQI is equal to S(1-1/N) where S is the average stars (or median) and N is the number of votes. As N approaches infinity, (1-1/N) approaches 1 and RQI approaches S. One issue with this metric is that harder routes get fewer ascents and therefore less votes, making it difficult for hard routes to make it into the “classic” class. We will use the Adjusted RQI (ARQI), which corrects for bias of RQI towards easier routes by adjusting the number of votes and therefore doesn’t make route quality a “popularity metric.” The ARQI is equal to S(1-1/Nw) where Nw is the number of weighted or adjusted votes and is determined by the votes-per-route for each grade. According to the OpenBeta, the categories for route quality are the following:

Classic: ARQI >= 3.5
Area Classic: 2.5 <= ARQI < 3.5
Good: 1.5 <= ARQI < 2.5
Bad: 0.5 >= ARQI < 1.5
Bomb: ARQI < 0.5

Class Distribution

Note that some routes with a lower ARQI may have a higher median rating. The ARQI takes the number of votes into consideration. This allows for a more accurate and fair route designation (we don’t want just any route falling into a classic).

At the state level, we found that a majority of routes fall in the Good to Area Classic range with outliers in the Bad class. But what about by grade?

We find that a majority of easy and intermediate routes are both classic and area classics, which supports my claim that anyone can climb a classic not only at their local crag but additionally famous big walls climbed by the legends.

Route Mapping

After some exploratory data analysis, I wanted to experiment with the functionality of my shiny app. I wanted to design a route finder that would combine a recommendation and route ranking system in a map format using geolocation and ratings data. I used Plotly for interactivity, Mapbox for geocoding, and Shiny for construction of the web application. I accessed a public token from Mapbox in order to do some basic plotting and interactivity with Plotly. First I plotted all parent walls for both trad and sport and colored each wall based on its highest quality route. Then with the idea that the user could filter routes by type, I plotted the routes by type and improved the formatting to be colored and sized by the ARQI (adjusted median rating).

Plot

After setting various filters on the app, a map colored and sized by route quality would be provided to help the climber find the best possible routes in their ideal range.

Recommendations

For the recommendation system, I will create an item based collaborative-filtering recommender which asks the question “for users who climbed route x, which routes did they also climb?” and can predict routes based on past preferences of other users (1). From what I’ve seen on famous route finders like theCrag or MP, these platforms do not implement recommendation systems for their routes (4, 5). They usually order the routes by popularity (average ratings or number of votes) but any data analyst using mean, median, or count as a metric for popularity should know to always consider outliers, skewed data, and relative proportions. In addition, I think having a simple recommendation system would be ideal for new climbers looking to find their first projects. I believe that a recommendation system combined with a map of route quality by the AQRI score also benefits the experienced climber too. For example, if they disagree with the location, rating or quality assessment of a certain route and as a result, a failed recommendation to the climber, the user can enter more data into the Mountain Project (where OpenBeta gets its data) which they believe is more accurate. When the data funneling into the model becomes more accurate, you get a better recommendation, a better user experience, increased retention, and so on.

Item based recommendation

My main reference for creating a simple item based reccomendation comes from (6). Here I am taking the complete cases of my entire ratings dataset. Since recommendation systems are so computationally heavy, I had to get rid of any observations with nulls to decrease the load. This is definitely a limitation to the accuracy of the recommendation.

Find a route we care about

We are going to choose a route to get a recommendation for in the California area. We will choose the “most popular route” by the sum of votes.

Overview

Peanut Brittle: Oregon easy 5.8; good sport route at the Peanut Wall in Smith Rock

IBCF answers the question “climbers who climbed Peanut Brittle also climbed…?”

or_ratings %>% 
  filter(route_id == "105790438")  %>%
  select(route_id, route_name, grade, type, parent_sector, class, level) %>%
  slice(1)

## # A tibble: 1 × 7
##   route_id  route_name     grade type  parent_sector  class level       
##   <chr>     <chr>          <fct> <chr> <chr>          <fct> <fct>       
## 1 105790438 Peanut Brittle 5.8+  sport (h) The Peanut good  intermediate

Create user-product matrix

First we spread out our users, route ID, and ratings across a pivot table that we convert to a simple matrix, or the user-product matrix, for calculating similarity scores.

Calculate degree of sparsity

99% of cells lack data… another limitation to this method. But we may be able to tackle this issue with cosine similarity.

Use cosine similarity to measure distance

We use cosine similarity to measure distances versus the Euclidean distance because cosine looks at directional similarity rather than magnitudal differences. Here I am hoping to capture beyond the numbers and get the content that the numbers tell. For example, a route that gets a rating of 3.0 four times and 4.0 eight times will have a 100% similarity score to a route that has one 3.0 ratings and two 4.0 ratings. If we were computing euclidean distance, this would give us a similarity of only 13%. I’m hoping that this method can be viable in tackling the data sparsity issue.

library(lsa)

route_x <- c(4, 8)
route_y <- c(1, 2)

cosine(route_x, route_y) # cosine

##      [,1]
## [1,]    1

1/(1 + sqrt((1-4)^2 + (2-8)^2)) # euclidean

## [1] 0.1297319

Compute across a matrix

We then can use a function to compute the simlarity for various routes in our matrix.

cos_similarity = function(A,B){
  num = sum(A *B, na.rm = T)
  den = sqrt(sum(A^2, na.rm = T))*sqrt(sum(B^2, na.rm = T)) 
  result = num/den

  return(result)
}

Apply this function to obtain Product-Product matrix

To prevent memory overload, we create a function to calculate the similarity only on the route we choose.

route_recommendation = function(route_id, rating_matrix = or_mat, n_recommendations = 5){

  route_index = which(colnames(rating_matrix) == route_id)

  similarity = apply(rating_matrix, 2, FUN = function(y) 
                      cos_similarity(rating_matrix[,route_index], y))

  recommendations = tibble(ID = names(similarity), 
                               similarity = similarity) %>%
    filter(ID!= route_id) %>% 
    top_n(n_recommendations, similarity) %>%
    arrange(desc(similarity)) 

  return(recommendations)

}

Get reccomendations for some route

Our function returns the top 5 similar routes to Snake Dike.

my_route <- "105790438"
recommendations = route_recommendation(my_route)
recommendations

## # A tibble: 5 × 2
##   ID        similarity
##   <chr>          <dbl>
## 1 105812662     0.122 
## 2 106776023     0.109 
## 3 105826816     0.0940
## 4 106303364     0.0842
## 5 107118805     0.0807

Join with ratings data

Next, we can join back to our original data to get information about the recommended routes. To build upon this method, I could implement machine learning frameworks like caret or tidymodels in R such as the K-Nearest Neighbors algorithm to compute the cosine similarity more accurately with cross validation and hyperparameter tuning. My biggest concern is that using this method will overload the Shiny app.

## # A tibble: 5 × 13
##   ID     name   similarity grade type  state sector_ID parent_sector   lon   lat
##   <chr>  <chr>       <dbl> <fct> <chr> <chr>     <dbl> <chr>         <dbl> <dbl>
## 1 10581… Cave …     0.122  5.4   trad  Oreg… 118897491 Southside     -121.  44.4
## 2 10677… West …     0.109  5.3   trad  Oreg… 118897491 Southside     -121.  44.4
## 3 10582… Sky R…     0.0940 5.8+  trad  Oreg… 105826813 (1) Northeas… -121.  44.4
## 4 10630… South…     0.0842 5.3   trad  Oreg… 118897491 Southside     -121.  44.4
## 5 10711… Mines…     0.0807 5.8+  trad  Oreg… 105865164 (3) Hand Job… -121.  44.4
## # … with 3 more variables: ARQI_median <dbl>, class <fct>, level <fct>

shiny app

In the app, the ser will be able to filter grade range, type, location, and rating on the Shiny app.

Conclusion

Another limitation of my project is the restriction placed on the data I’m using. Following a legal battle with onX regarding a copyright infringement, which OpenBeta won (as noncommercial and educational factual data cannot be copyrighted), OpenBeta is working to release their data under a public domain, permissive license (1,3). For this reason, all of OpenBeta’s current datasets only include user ratings up to 2020, and it doesn’t seem like they will be able to update them by August. Therefore, there is a missed opportunity for generating better recommendations without input following the increase of climbers after Tokyo. In the future, climbing data from the Mountain Project will be streamed directly into the model prior to rollouts and will allow for optimal and more accurate results or recommendations.
In summary, I plan to provide a recommendation engine and route quality mapping system to climbers to streamline the route searching process for climbers of varying skill sets. I truly believe that any stakeholder (like athletes, sponsors, spectators, media, businesses, brands, participants, etc.) could benefit from this project. Guiding the recent explosion of climbers properly could help make the sport extremely profitable and the climbing community greater and diverse. I hope to help dissolve barriers to entry by providing a tool to climbers that can be utilized as a spot to keep them satisfied, safe, and yearning for more. For the data community, I also want to promote the open source movement in software and data as I strongly believe that it is essential in encouraging innovation, attracting diverse talent, and broadening perspectives within tech.